軟體開發時，都會有一份「程式開發規範」，用來說明（X）限制（O）程式撰寫方式，原本用意應該是為了讓整體的程式有一致性，對於維護時，看程式會比較好抓到脈絡，也可以當作是提醒，記得要檢查低級錯誤，或是 code review時有個嫌棄的依據。如果有好好遵守，對於提升程式品質是有用的。

但要注意若內容過於太嚴苛，可是會佔用開發時間，造成Delay，當是要趕進度或是緊急Bug修正時，為了code style而不能PR/merge，是會把人搞瘋的。然後吵上去，PM跟長官九成九都是以對外交付為優先考量，規範通常就是被丟在一旁，或者就是一句以後要記得review補回來（PR/merge後，八成就不會再有人動了，沒事就不要動code，少做少錯是系統穩定的鐵則之一）。

語言特性都有其理念，官方都有code style 的建議版本，專案裡用到的語言越多（例如現代流行的前後端分離，至少就兩份標準為低消），在這方面就越難管理，而對於reviewer也是很困難，對於不熟的程式語言要怎麼看出寫法潛在問題，跟本就…看不懂麻，所以又只能回歸到作者的細心，用心度上面。當然也可以一種語言就配一個reviewer，但成本就會一直墊高。有的時後真的不要嫌開發很貴，就是因為現代規定越來越多，雖然可以反應在品質上，但是那個不是免費的！

所以如何製定這份規則，也是會一個考量的點，一般通常會由比較資深/熟悉語言，或者是官位比較大的制定這份「程式開發規範」，若是小公司的話，通常也不會有固定的內容或格式，就依公司風氣，成員習性來一起制定，實際成效會比較好一點（參與人總不能嘴砲講一講，最後都不做，這樣很快就會被看破手腳XD）。而大公司有的是傳統，就是照公司規定就是，反正大公司有錢不怕找不到人？！

而在規範上，通常就會牽扯到naming，就是那個工程師最煩惱的naming！但是好的naming真的會讓整體維護，或是閱讀上好了解非常多。為了不要讓實作的工程師花太多時間在煩惱naming（嗯，曾經有碰過一個interface 定義吵個兩三天以上，程式都不用寫了，光想名字時間就用光了）。最好由SD或資深工程師先把目錄規則，系統/子系統檔案結構，class diagram 上層關係與關聯的內容定好。也可以另外寫規則（建議規則），但不列入開發規範內，依語言特性各自發揮，也保有一些限制跟思考防呆，再給個sample，後面就算是菜鳥照著copy改一改，應該也就順了。

不過如果參與的專案，或是公司有這份文件的話，其實可以多留意把他存下來，以後真的要制定時就有素材，有基本的依據可以參考使用！

最後回歸到人本，程式是人寫的，雖然可以就事論事，但還是會受到個人的意願跟情緒影響。近年來，覺得現在寫程式，IQ不是最重要的因素，有沒有心，跟熱情才是重點。能力很高，但因為心情不佳，不肯發揮實力或是偷懶，神人也只有廢物輸出。所以有時候搏感情，團隊氣氛真的很重要，至少人在舒適，信任有衝勁的氣氛下，戰力可以有80%以上的發揮沒問題！